Update README with versioning information #704
Conversation
|
/cc @fjl, @lightclient, @LukaszRozmej, @macfarla and any other client devs I missed, would be great to get your feedback here too! |
|
@kclowes take a look at EIP for versioning EIP's, maybe you will have some inspiration: https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7577.md |
danceratopz
left a comment
danceratopz
left a comment
There was a problem hiding this comment.
Good idea. I think adding/removing might be the wrong way around though? Adding something doesn't break anything for users, whereas removing it does.
| Examples of changes by version type: | ||
|
|
||
| **Major:** | ||
| - Adding new RPC methods |
There was a problem hiding this comment.
| - Adding new RPC methods | |
| - Removing an existing RPC method |
| - Adding new fields to response objects | ||
|
|
||
| **Minor:** | ||
| - Removing an existing RPC method |
There was a problem hiding this comment.
| - Removing an existing RPC method | |
| - Adding a new RPC method |
There was a problem hiding this comment.
I think both adding and removing should be in major. Here we are talking about what breaks hive tests not what breaks user experience. As such, both adding and removing is a major break in hive
4 participants
The idea with this versioning scheme is to minimize breaking cycles for client developers. As it stands, any new PR merged has the potential to cause failures in hive's rpc-compat test runs. I think it would be good to have a hive rpc-compat run against main with the latest changes, but to also have another rpc-compat hive run that runs against a stable version of this repo so we can give clients time to upgrade without flagging new changes as failures right away. Since the current version is 1.0.0-beta.4 I propose we tag what's currently in main as v1.0.0 and then we can start merging things like #678.